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PRIORITY CLAIM 

This application claims benefit of priority of provisional application Serial No. 
60,466,623 entitled "System and Methods Employing a PEPt Architecture for RPC" filed 
5 April 30, 2003, whose inventor is Harold Carr. 

BACKGROUND OF THE INVENTION 

10 1. Field of the Invention 

This invention relates to computer software, and more particularly to remote 
procedure call (RPC) systems. 

15 2. Description of the Related Art 

Remote Procedure Call (RPC) is a protocol that one program can use to request a 
service from a program located in another computer in a network without having to 
understand network details. A procedure call is also sometimes referred to as a function 

20 call or a subroutine call. RPC uses the client/server model. The requesting program is a 
client and the service-providing program is the server. Similar to a regular or local 
procedure call, an RPC is a synchronous operation requiring the requesting program to be 
suspended until the results of the remote procedure are returned. However, the use of 
lightweight processes or threads that share the same address space allows multiple RPCs 

25 to be performed concurrently. 

When program statements that use RPC are compiled into an executable program, 
a stub is included in the compiled code that acts as the representative of the remote 
procedure code. When the program is run and the procedure call is issued, the stub 
30 receives the request and forwards it to a client runtime program in the local computer. 
The client runtime program has the knowledge of how to address the remote computer 
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and server application and sends the message across the network that requests the remote 
procedure. Similarly, the server includes a runtime program and tie that interface with the 
remote procedure itself. Results are returned in a similar way. 

5 JAX-RPC (Java API for XML-Based RPC) is an application program interface 

(API) in the Java Web Services Developer Pack (WSDP) that enables Java developers to 
include remote procedure calls (RPCs) with Web services or other Web-based 
applications. JAX-RPC is aimed at making it easier for applications or Web services to 
call other applications or Web services. JAX-RPC provides a programming model for the 
10 development of-SOAP- (Simple Object -Access Protocol)-based applications. The JAX- 
RPC programming model simplifies development by abstracting SOAP protocol-level 
runtime mechanisms and providing mapping services between Java and the Web Services 
Description Language (WSDL). 

15 The specification and implementation of Remote Procedure Call (RPC) systems 

have retread the same ground in many forms, from DCE, to distributed versions of C++, 
to COM/DCOM, CORBA, RMI and RMI-HOP, to the more recent XML-RPC and 
SOAP. The specification and implementation of these systems seems to traverse the 
same ground repeatedly. Therefore, it is desirable to isolate the key concepts of RPC 

20 systems into a core, high-level RPC architecture that may provide a basis for developing 
and implementing RPC systems. 
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SUMMARY 



Embodiments of a system and method for employing a Presentation, Encoding, 
Protocol and transport (PEPt) architecture for Remote Procedure Call (RPC) systems are 
5 described. Embodiments of the PEPt architecture may decompose RPC systems into 
presentation, encoding, protocol, and transport blocks. Presentation may encompass the 
data types and APIs available to a programmer. Encoding describes the representation of 
those data types on the wire. Protocol frames the data encoding to denote the intent of the 
message. Transport may move the encoding and protocol from one location to another. 
10 The PEPtarchitecture-preferably may-allow the-user- to understand, use and-implement 
RPC systems by providing a simple but comprehensive framework in which to place 
finer-grained details of distributed communications systems. Embodiments of the PEPt 
architecture may serve as core, high-level RPC architectures and may provide a basis for 
understanding and implementing RPC systems. 

15 

In one embodiment, to send outgoing messages on a remote procedure call system 
using the PEPt architecture, a presentation block on a system may present data types and 
Application Programming Interfaces (APIs) available to a program on the system. The 
APIs may be configured to provide an interface to the remote procedure call system to the 

20 program on the system. An encoding block may encode representations of those data 
types (for data received from the program) as outgoing messages on an interconnect. In 
one embodiment, to encode representations of those data types as outgoing messages, the 
encoding block may convert representations of data provided by the program to 
representations of data for use by the remote procedure call system. In one embodiment, 

25 the encoding block may generate a text encoding of the data types. In one embodiment, 
the encoding block may generate a binary encoding of the data types. A protocol block 
may frame the encodings to denote the intent of the outgoing messages. In one 
embodiment, the protocol block may denote if the outgoing messages are request 
messages or response messages to request messages received by the program. In one 

30 embodiment, if the messages are response messages, the protocol block may determine if 
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the response message is an error message and, if so, denote in the outgoing message that 
the message is an error message. A transport block may move the encoded and protocol 
framed outgoing messages from the system to a remote system over the interconnect. In 
one embodiment, the transport block may move the encoded and protocol framed 
5 outgoing messages from the system to the remote system over the interconnect using 
TCP/IP. In other embodiments, other transports may be used to move the outgoing 
messages over the interconnect. 

In one embodiment, to receive incoming messages on a remote procedure call 
10 system using the PEPt architecture, the transport-block may receive encoded andprotocol 
framed incoming messages from the remote system over the interconnect. The protocol 
block may determine the intent of the encoded and protocol framed incoming messages. 
In one embodiment, the protocol block may determine if the incoming messages are 
reqeuest messages or response messages. In one embodiment, the protocol block may 
15 determine if the incoming messages are error messages and, if so, either handle the error 
message itself or alternatively pass the error message on to the encoding block to be 
handled elsewhere. The encoding block may decode representations of data types from 
the incoming messages and pass the decoded data on to the presentation block. The 
presentation block may then provide the decoded data types from the incoming messages 
20 to the program on the system. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



Figure 1 illustrates a system implementing an RPC system using a PEPt 
5 architecture according to one embodiment. 

Figure 2 illustrates a high-level view of the PEPt architecture according to one 
embodiment. 

10 Figure 3 illustrates the fundamental building blocks of the PEPt architecture 

according to one embodiment, and shows interfaces that represent or bridge the blocks of 
the core architecture. 

Figure 4 is a table showing the blocks and interfaces used to invoke and service a 
15 remote procedure for the client side according to one embodiment. 

Figure 5 is a table showing the blocks and interfaces used to invoke and service a 
remote procedure for the server side according to one embodiment. 

20 Figure 6 is a flowchart illustrating a method of sending outgoing messages on a 

remote procedure call system using the PEPt architecture according to one embodiment. 

Figure 7 is a flowchart illustrating a method of receiving incoming messages on a 
remote procedure call system using the PEPt architecture according to one embodiment. 

25 

While the invention is described herein by way of example for several 
embodiments and illustrative drawings, those skilled in the art will recognize that the 
invention is not limited to the embodiments or drawings described. It should be 
30 understood, that the drawings and detailed description thereto are not intended to limit the 
invention to the particular form disclosed, but on the contrary, the intention is to cover all 
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modifications, equivalents and alternatives falling within the spirit and scope of the 
present invention as defined by the appended claims. The headings used herein are for 
organizational purposes only and are not meant to be used to limit the scope of the 
description or the claims. As used throughout this application, the word "may" is used in 
5 a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense 
(i.e., meaning must). Similarly, the words "include", "including", and "includes" mean 
including, but not limited to. 
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DETAILED DESCRIPTION OF EMBODIMENTS 



Embodiments of a system and method for employing a Presentation, Encoding, 
Protocol and transport (PEPt) architecture for Remote Procedure Call (RPC) systems are 
5 described. A protocol block and encoding block may deal with the situation where 
fragments of a request are sent, causing a reply (complete or fragment) to be received 
even before marshaling is complete. This can happen, for example, in RMI-HOP when 
the server-side detects an error early in processing or forwards the request to a different 
object. Embodiments of the PEPt architecture provides basic building blocks to 

10 preferably allow users to avoid -'rein venting the- wheel" when developing RPC systems. 
To isolate the key concepts of RPC systems into a core architecture, embodiments of the 
PEPt architecture may decompose RPC systems into presentation, encoding, protocol, 
and transport blocks. With such an approach, one aspect of the RPC may evolve without 
disturbing the others. In other words, when an alternate encoding, protocol or transport is 

15 desired there may be no need to create another presentation block. Alternatively, a new 
presentation block may reuse existing protocols, encoding and transports. 

The PEPt architecture may include, but is not limited to, presentation, encoding, 
protocol and transport blocks. Presentation may encompass the data types and APIs 

20 available to a programmer. Encoding describes the representation of those data types on 
the wire. Protocol frames the data encoding to denote the intent of the message. 
Transport may move the encoding and protocol from one location to another. The PEPt 
architecture preferably may allow the user to understand, use and implement RPC 
systems by providing a simple but comprehensive framework in which to place finer- 

25 grained details of distributed communications systems. Embodiments of the PEPt 
architecture may serve as minimal, high-level RPC architectures and may provide a basis 
for understanding and implementing current and future RPC systems. 

The PEPt architecture may define commonalities for RPC technologies. It may 
30 seem RPC systems have little or nothing in common. RPC systems based on 
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technologies such as Hypertext Transfer Protocol (HTTP), Simple Object Access 
Protocol (SOAP), and Remote Method Invocation Internet Inter-ORB Protocol (RMI- 
IIOP), appear to be quite varied. For example, Common Object Request Broker 
Architecture (CORBA) and Distributed Component Object Model (DCOM) both layer a 
5 Distributed Object Computing (DOC) model on the RPC model of Distributed 
Computing Environment (DCE). Remote Method Invocation (RMI) provides a Java- 
centric DOC model. RMI-HOP makes it possible for the RMI and CORBA DOC models 
to interact. Extensible Markup Language Remote Procedure Call (XML-RPC) and SOAP 
use XML to represent procedure calls over the Internet. It is noted that SOAP, like 
10 systems that preceded it, repeats the design, specification and implementation-of concepts 
covered in previous systems. Embodiments of the PEPt architecture preferably serve as 
the basis for RPC infrastructure reuse between these seemingly disparate RPC systems. 

Embodiments of the PEPt architecture may be applied to RPC systems based on 
15 any of the above technologies or other RPC technologies. To avoid the cycle of 
reinvention as RPC systems evolve, the PEPt architecture may be employed as a high- 
level framework to structure design and implementation of RPC systems. The PEPt 
architecture may employ alternate protocols and transports, as well as revisions in stubs 
and encodings. To build or use more than one RPC system, the PEPt architecture may 
20 allow organization of an RPC approach by providing a structure that preferably provides 
clarity as to where a function belongs, makes it easier to evolve the system over time, is 
comprised of a small number of pieces, and specifies a simple decomposition of RPC 
systems which may universally apply. 

25 The PEPt architecture may facilitate the design, specification, implementation, 

and maintenance of RPC systems. The organization and division provided by PEPt 
preferably allow the architecture to be grasped in its entirety, while being comprehensive 
enough to describe and implement diverse RPC systems. The PEPt architecture is 
illustrated below using a running example involving RMI-EOP and JAX-RPC (Java API 

30 for XML-Based RPC). The primary artifacts used by programmers when using an RPC 
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system, stubs and Ties, are discussed in the relationship to PEPt. The PEPt architecture 
may support client-side operation of stubs and server-side operation of Ties. In one 
embodiment, the architecture may be symmetric on the client and the server: on the client 
side, a programmer may make a remote call with arguments of specific types 
5 (presentation). The types are converted into a representation agreed upon by both the 
client and server sides (encoding). The encoding is framed with information that carries 
the intent of the message (protocol). The raw bits of the encoding and presentation are 
moved from the client location to the server location (transport). The server side goes 
through these steps in reverse until it obtains the arguments to call the procedure. The 
10 whole process" repeats itself to return "a result;- PEPt RPC systems may -implicitly or - 
explicitly carry out these steps. PEPt provides the ability to structure the design of RPC 
systems to allow a scalable, reusable, and maintainable infrastructure. 

PEPt provides a high-level, language-independent view of RPC not necessarily 
15 tied to a particular type of RPC system. PEPt presents an architecture for RPC with fewer 
"moving parts" in order to guide the overall structuring of a system. The SOAP and Web 
Services Description Language (WSDL) specifications allow the specification of different 
transports and encodings. PEPt is an architecture in which to implement such 
specifications. 

20 

In one embodiment, the PEPt architecture may be language and programming 
model independent. PEPt organizes RPC systems to define data types (presentation), 
wire representation of those types (encoding), framing information (protocol) and a way 
to move the encoding and protocol bits from one location to another (transport). PEPt 
25 shows the responsibility and relationships between these fundamental RPC building 
blocks. 

Embodiments of the PEPt architecture may be applied, for example, in CORBA 
systems. In one embodiment, PEPt may be applied to a system supporting RMI-HOP 
30 stubs and Ties dynamically switching between HOP and SOAP/HTTP. The core RPC 



Atty. Dkt. No.: 5681 -6430 1/P9233 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P C. 



architecture may serve as the basis for understanding, designing, implementing, 
maintaining and reusing RPC systems. Embodiments of the PEPt architecture may 
support or allow one or more of, but not limited to, transactions, security, threads and 
thread pools, and connection caches. 

5 

Using embodiments of the PEPt architecture, invoking SOAP-based web services 
from a general RPC system need not be difficult. PEPt isolates the main complexity to 
where it should be - in the data that is sent back and forth. 

10 ~ Since most underlying protocols are asynchronous, embodiments of the PEPt 
architecture may, for example, serve as the basis for messaging systems, thus unifying 
conception and implementation of those systems. The presentation block may be 
partitioned into two dimensions: synchronous versus asynchronous, and message API 
versus method call. In one embodiment the PEPt architecture may support issues such as 

15 messaging store and forward. 

Figure 1 illustrates a system implementing an RPC system using a PEPt 
architecture according to one embodiment. System 200A may be any of various types of 
devices, including, but not limited to, a personal computer system, desktop computer, 

20 laptop or notebook computer, mainframe computer system, workstation, network 
computer, Personal Digital Assistant (PDA), cell phone, pager, smart appliances or other 
suitable device. In general, system 200A may be any device with a digital heartbeat. 
System 200A may include at least one processor 202. The processor 202 may be coupled 
to a memory 204. Memory 204 is representative of various types of possible memory 

25 media, also referred to as "computer readable media." Hard disk storage, floppy disk 
storage, removable disk storage, flash memory and random access memory (RAM) are 
examples of memory media. The terms "memory" and "memory medium" may include 
an installation medium, e.g., a CD-ROM or floppy disk, a computer system memory such 
as DRAM, SRAM, EDO RAM, SDRAM, DDR SDRAM, Rambus RAM, etc., or a non- 
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volatile memory such as a magnetic media, e.g., a hard drive or optical storage. The 
memory medium may include other types of memory as well, or combinations thereof. 

System 200A may include, in memory 204, an implementation of an RPC system 
5 using the PEPt architecture, which may include presentation 100A, encoding 102A, 
protocol 104A, and transport 106A blocks. System 200A may couple over a network via 
one or more wired or wireless network interfaces to one or more other devices such as 
system 200B which may, but do not necessarily, include an implementation of the RPC 
system, using the PEPt architecture which may include presentation 100B, encoding 
10 102B, protocol 104B, and transport 106B blocks. In one embodiment,; system 200 A may 
be a client (or server), and system 200B a server (or client), in a client/server RPC model. 

While Figure 1 illustrates an exemplary scenario in which both systems 200A and 
200B include an implementation of an RPC system using an embodiment of the PEPt 

15 architecture, note that, in one embodiment, a client system such as system 200B using the 
PEPt architecture may communicate with a server such as system 200A using another 
technology as long as both systems agree on the underlying wire protocol. Similarly, in 
one embodiment, a client system such as system 200B using another technology may 
communicate with a server such as system 200A using the PEPt architecture as long as 

20 both systems agree on the underlying wire protocol. 

Figure 2 illustrates a high-level view of the PEPt architecture according to one 
embodiment. In this embodiment, the PEPt architecture organizes RPC systems into the 
fundamental building blocks of: Presentation 100, Encoding 102, Protocol 104 and 

25 Transport 106. These blocks may be referred to as a group as PEPt. Figure 2 shows the 
blocks so as not to suggest a layered architecture. However, the PEPt architecture may be 
realized in layers, but that is not required. PEPt's four main building blocks are 
preferably fine-grained enough to provide a useful division of concerns to answer 
placement of more detailed functionality and course-grained enough to understand as a 

30 whole. 
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Each PEPt block is responsible for an RPC operation. Presentation 100 
encompasses the data types that may be passed between remote systems and the APIs a 
programmer uses to contact or implement a remote service. For the data types to be 

5 passed, encoding 102 may place the data types in a standard representation understood by 

. ■ _ 

both ends of a remote call independent of the underlying hardware, operating system and 
programming language. When sending representations of data from one system to 
another, each end of the conversation should understand the intent of the data. For 
example, a client makes a request and a server makes a response. The protocol 104, 
10 which surrounds the data- exchanged, differentiates - message exchanges to- determine 
requests and responses. The transport 106 moves the encoding 102 and protocol 104 bits 
from one location to another. These blocks are described in more detail below. 

A programmer may interact with an RPC system through client-side stubs and 
15 server-side Ties (although the work of stubs and Ties may also be done "by hand"). Stubs 
and Ties convert local procedure calls to remote procedure calls. The APIs used to obtain 
and manipulate stubs and Ties, and the data types that a programmer may use with an 
RPC system, may be part of presentation 100. Once a programmer has a stub or Tie, 
passing and returning instances of data types from the programming language being used 
20 may be called or serviced. For example, passing the string "INTU" to a stock quote 
service stub might result in the double 49.89. 

Each RPC system may allow certain data types to be transferred. This may vary 
from system to system. For example, XML-RPC supports scalars (e.g., ints, Booleans, 
25 strings, base64), structs and arrays. The JAX-RPC version of SOAP supports strings, 
ints, longs, Boolean, base64, hexBinary, etc., as well as structs and arrays (and plug-in 
serializers for other types.) RMI supports all primitive Java data types, java.lang.Objects 
that derive from java.io.Serializable and arrays. 

30 Presentation 100 may include communicating errors to programmers through 
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stubs and Ties. Different RPC systems may handle errors in different ways. For 
example, JAX-RPC and RMI-EOP map errors to Java Exceptions. XML-RPC errors are 
a fault struct that contains an int faultCode and a string faultString (similar to HTTP). 
Presentation 100 may translate encoded representations of errors into something used by 
5 programs. Presentation 100 may include one or more APIs that may be used to interact 
with an RPC system, the data types that may be transferred, and error reporting. 

Changing the form of data for communication may be a concern for RPC systems. 
This may be addressed by the encoding block 102. Encoding 102 may include the 
10 representation of instances of data types -understood by- all parties involved in. the . _ 
communication. Encoding 102 may convert representations of data used by the 
programming language in use to representations agreed for use by the RPC system 
participants. To illustrate, suppose for example a C programming language string such as 
"INTU" is in computer memory (where A is a memory address): 

15 



A(n) 


A(n+1) 


A(n+2) 


A(n+3) 


A(n+4) 


T 


'N' 


T 


V 


null 



This representation might not be understood by the system on the other end. 
Therefore, an agreement is reached on how to represent strings. In XML-RPC it might 
20 look like: 

<string>INTU</string> 

In CORBA's Common Data Representation (CDR), the representation may be 
25 similar to the C memory representation but preceded by a length field (not to mention 
possible padding after the string itself). Similarly, the result of such a remote call might 
be 49.89 (assuming a successful call - errors are discussed later). This may be 
represented in XML-RPC as: 
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<double>49.89</double> 



An RPC system specification defines the representation (encoding) for each 
primitive data type available at the presentation level. The representation of aggregates of 
5 primitive types and other aggregates may also be specified. The result is a representation 
that is understood by both ends of a remote call regardless of hardware/operating system 
or language. The term "encoding block" may denote the "wire" representation and the 
conversion process from language representation to wire representation. 

10 - Data-by itself makes no-sense.- Other-information may need Jq_be included along 

with the data to indicate the intent of the data. For example, when sending a string to an 
echo service, the information needs to indicate that the same string is to be received as a 
reply. The protocol block 104 is responsible for "framing" the encoded data to indicate 
the intent of the message. 

15 

Protocols vary widely. Comparing a CORBA request to a string echo service to a 
SOAP request to the same service illustrates this point. Sending the string "Testing HOP 
out of framework" in CORBA's CDR binary representation may look like: 
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35 In SOAP a similar request may look like: 
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<?xml version= n 1 .0" encoding="UTF-8"?> 
<SOAP-ENV:Envelope 

SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/spap/encoding/ ,, 
xmlns:SOAP-ENC= n http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:SOAP-ENV= n http://schemas.xmlsoap.org/soap/envelope/ u 
xmlns:xsd= M http://www.w3.org/2001/XMLSchema n 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance M > 
<SOAP-ENV:Body> 

<m:echoString xmlnsrm^'httpV/soapinterop.org/'^ 
<inputString>Testing SOAP</inputString> 
</m:echoString> 
</SOAP-ENV:Body> 
</SOAP-ENV:Envelope> 

The ease of use of SOAP's text encoding compared to CORBA's binary encoding 
may give SOAP an advantage in the early part of the learning and adoption curve. 
SOAP's use of XML tagged data may also be advantageous in handling missing or extra 
data for schema evolution. A binary encoding may be advantageous for performance. In 
20 one embodiment, input objects and output objects may isolate encoding changes from the 
rest of the system. This may be important, for example, when switching from a self- 
describing encoding to a binary encoding. A self-describing encoding may handle extra 
or missing data. A binary encoding may be more compact but may require more 
agreement between parties. 

25 

The protocol block 104 may differentiate requests from responses. On the 
sending side, protocol 104 may frame the encoded data with the intent of the message. 
On the receiving side, protocol 104 may interpret the intent. For example, responses may 
be errors. In this case, the receiving side protocol 104 may handle the error (e.g., try a 
30 different server location) or alternatively pass the error to the encoding block 102 which 
may then convert the error into something used by the presentation block 100. To be able 
to make this choice, protocol 104 needs to interpret the intent of the message. In this 



5 



10 
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case, the intent is to handle or signal an error, rather than return a result. Protocol 104 
says and interprets what a message means. 



The transport block 106 moves a request or response (e.g., the encoded data and 
5 protocol framing) from one location to another. The most common transport today is 
TCP/IP. CORBA HOP requests and responses use TCP/IP as their transport. SOAP 
often uses HTTP as a "transport". However, HTTP is a protocol in its own right, and uses 
TCP/IP as its transport. Besides carrying the basic SOAP message (encoding + protocol) 
HTTP needs its own protocol bits. Taken as a whole, the bits that are sent over TCP/IP 
10 for a SOAP/HTTP message may be, for example: 

POST/scripts/SalSAPl.dll/SaServletEngine.class/hp-soap/soap/rpc/interop/EchoService HTTP/1 .0 
Host: www;openhc.org 
User-Agent: openhc SOAP Client/0.1 
15 Content-Type: text/xml; charset="us-ascii" 
Content-Length: 528 
SOAPAction: "http://soapinterop.org/" 
<?xml version="1.0" encoding="UTF-8"?> 
<SOAP-ENV: Envelope ...> 

20 

</SOAP-ENV:Envelope> 

This illustrates two levels of protocol: The HTTP protocol (e.g., POST, Content- 
Type) and the SOAP payload. In general, PEPt views transport 106 as a source or sink 

25 from which bits are sent or received with no further need for PEPt to deal with additional 
protocol information. Thus, PEPt views CORBA HOP as a protocol and TCP/IP as a 
transport. In the SOAP/HTTP case, PEPt would view HTTP as a protocol framing the 
SOAP message that, in turn, frames the encoded data. The entire HTTP protocol plus 
SOAP payload is then given to a TCP/IP transport. PEPt is flexible enough to allow 

30 various degrees of coupling between transport 106 and protocol 104 to handle multiple 
layers of protocols, as in the SOAP/HTTP case. Once protocol 104 is done forming a 
message it gives it to transport 106 to send. Conversely, when transport 106 receives a 
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message it gives it to protocol 104 for handling. Transport 106 is responsible for 
transferring requests and responses from one location to another. 

PEPt enables traditional interactions between blocks, but in some embodiments 
5 may also allow private contracts between blocks. For example, if a protocol supports 
fragmentation, then encoding 102 may need to signal protocol 104 when encoding 102's 
internal buffers are full, even though marshaling may not be complete. Protocol 104 may 
need to form a fragment message and give it to transport 106 to be sent. Embodiments of 
the PEPt architecture may allow such coupling in a generic manner. 

10 " " ~ - - 

Figure 3 illustrates the fundamental building blocks of the PEPt architecture 
according to one embodiment, and shows interfaces that represent or bridge the blocks of 
the core architecture. An example of how PEPt blocks (and interfaces) come into play in 
a client-server RPC system is described below for Figure 3 by examining exemplary 

15 RMI-HOP and JAX-RPC stubs and Ties and showing how the PEPt architecture supports 
stub and Tie operation. Using Figure 3 to follow an exemplary request/response lifecycle, 
in detail, on the client and server side, may serve to illustrate that PEPt's fundamental 
blocks provide the right level of granularity to implement RPC systems. Steps to support 
stub 110 and Tie 112 operation and relate those steps to specific RMI-HOP and JAX-RPC 

20 stubs 110 and Ties 112 are listed below, along with a description of how the PEPt 
architecture supports those steps. 

Client-Side Lifecycle 

The following description of the client-side lifecycle of a client-server RPC 
25 system describes means for presenting data types and Application Programming 
Interfaces (APIs) available to a programmer, means for encoding representations of those 
data types as messages on an interconnect, means for framing the encodings to denote the 
intent of the messages, and means for moving the encoded and protocol framed messages 
from one location to another over the interconnect. 
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From the programmer's point of view, calling a remote service 210 is similar to 
calling a local service. Calling a remote service 210 may include, but is not limited to: 
obtaining a reference to the remote service 210, invoking the reference with some 
arguments, and getting the result as an exception or return value. Showing more 
5 infrastructure detail, these steps may include, but are not limited to: 

• Obtain a reference to the remote service 2 10. 

• Invoke the reference with some arguments. 

- Get a connection to the remote service 210. 
Get an output stream for the connection. [CS1] 

10 - Marshal the arguments into the output stream. [GS2] 

- Marshal request complete. [CS3] 

- Send the arguments to the remote service 210. 

• Get the result as an exception or return value. 

- Wait for a response. 

15 - Get an input stream for the connection. [CS4] 

- Unmarshal the return value or exception from the input stream. [CSS] 

- If a normal return value, return it. [CS6] 

- If an exception (re)throw the exception. [CS7] 

- Release any resources used in the remote call. [CS8] 

20 

The following description shows how PEPt supports these steps. The labeled 
steps - e.g., [CS1] - relate the steps to code in example stubs and the following discussion 
of how that code connects to the PEPt architecture in the client side lifecycle. These steps 
are described in more detail below along with their relation to concrete RMI-EOP and 
25 JAX-RPC examples. 

Obtaining a Remote Reference 

A remote reference is obtained, which typically means having a stub 110 on which 
to invoke remote calls. A user of a remote service 210 may obtain a reference to that 
30 service. This bootstrap step may vary from system to system. In RMI-HOP, a reference 
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is generally obtained from invoking a method on another remote object, generally a 
conventional naming service. XML-based systems may create the reference directly from 
a URL or look up a URL in a registry. 

5 In terms of PEPt, obtaining a reference may result in a proxy being created 

(possibly downloaded) in the client. A proxy is sometimes referred to as a "stub" 110. 
The stub 110 contains the service's address information and code which (un)marshals data 
from/to the remote service 210. The address information may contain alternate addresses 
and other information such as transactional and security requirements. Once a stub 110 
10 has been i obtained, remote procedures (methods) maybe invoked. ....... . 

Invoking the Remote Reference 

To show an example of how PEPt may support both RMI-IIOP and SOAP, an 
example using the following echo service is described: 

15 

public interface RIBaselF extends java.rmi. Remote { 
public String echoString(String inputString) 
throws java.rmi. RemoteException; 

} 

20 

Portions of the corresponding RMI-IIOP and JAX-RPC stubs 110 are shown for 
this service to concretely show how they connect to the PEPt architecture at the remote 
call processing steps listed above. 

25 When a client calls a remote service 210, the client may be actually making a call 

on a stub 110. A stub 110 may be responsible for interfacing with the RPC infrastructure 
to accomplish the remote call. A stub 110 may be part of PEPt's presentation block: the 

programming model and data types applicable to that model. The model is invoking 

- 

methods on stubs 110 and getting return values or catching exceptions: 

30 

String result = null; 
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try { 

result = echoService.echoString( M Hello World!"); 
} catch (java.rmi.RemoteException) { 

} 

An exemplary echoString method for an RMI-HOP stub may be: 

public String echoString(String argO) 
throws RemoteException 

{ - - ■- - - - 

try { 

org.omg.CORBA_2_3.portable.lnputStream in = null; 
try { 

OutputStream out = _request("echoString", true); [CS1] 

out.write_value(argO, String.class); [CS2] 

in = jnvoke(out); [CS3] [CS4] 

return (String) in.read_value(String.class); [CSS] [CS6] 
} catch (Application Exception ex) { 

in = ex.getlnputStream();[CS4] 

String id = in.read_string();[CS5] 

throw new UnexpectedException(id); [CS7] 
} catch (RemarshalException ex) { 

return echoStringQ; 
} finally { 

_releaseReply(in); [CS8] 

} 

} catch (SystemException ex) { 
throw Util.mapSystemException(ex); 

} 

} 

Note that the stub's co-located optimization branch is not shown. 

A stub 110 may be independent of other blocks in the RPC infrastructure. This 
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exemplary stub illustrates this point as it only deals with presentation block 100A data 
types which may be written and read from output and input streams (e.g.., read_* and 
write_* methods defined on org.omg.CORBA_2_3.portable.InputStream). This stub is 
not tied to a particular encoding 102A, protocol 104A, or transport 106A. Specific parts 
5 of the stub's code are discussed below along with an examination of the processing steps. 

For the same interface, the echoString method for an exemplary JAX-RPC stub 
may be considerably more complex: 

10 public String echoString(String inputString) 

throws java.rmi.RemoteException 

{ 

try { 



15 



StreamingSenderState _state = _start(JiandlerChain); 
InternalSOAPMessage _request = _state.getRequest(); [CS1] 



_request.setOperationCode(echoString_OPCODE); 
RIBaselF_echoString_RequestStruct xx = 



20 



new R I Base I F_echoString_RequestStruct () ; 
xx.setlnputString(inputString); [CS2] 
SOAPBIocklnfo _body Block = 



25 



new SOAPBIocklnfo(ns1_echoString_echoString_QNAME); 
bodyBlock.setValue(xx); 
bodyBlock.setSerializer( 

myRIBaselF_echoString_RequestStruct_SOAPSerializer); 
jequest.setBody(Jx)dyBlock); 
state.getMessageContext().setProperty( 

HttpClientTransport.HTTP_SOAPACTION_PROPERTY, 

"http://soapinterop.org/"); 



30 



_send((String) _getProperty(ENDPOINT_ADDRESS_PROPERTY), _state); [CS3] 
RIBaselF_echoString_ResponseStruct yy = null; 

Object _responseObj = _state.getResponse().getBody().getValue(); [CS4] 
if (_responseObj instanceof SOAPDeserializationState) { 



yy = (RIBaselF_echoString_ResponseStruct) 
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((SOAPDeserializationState)_responseObj).getlnstance(); 
} else { 

yy = (RIBaselF_echoStringJ^esponseStruct)_responseObj; 
}[CS5] 

5 return yy.get_return(); [CS6] 

} catch (RemoteException e) { 

throw e; [CS7] 
} catch (JAXRPCException e) { 
throw new RemoteException(e.getMessage(), e); [CS7] 
10 } catch (Exception e) { 

if (e instanceof RuntimeException) { 
throw (RuntimeException)e; [CS7] 
} else { 

throw new RemoteException(e.getMessage(), e); [CS7] 

15 } 
} 

} 

This exemplary stub mixes protocol and encoding in what should be an essentially 
20 presentation block only stub. A JAX-RPC stub may be built which does not expose non- 
presentation block details. In one embodiment, the PEPt architecture may be used to 
create an RPC system that makes SOAP calls using RMI-EOP stubs. The main 
difference between these stubs is that RMI-HOP stubs may be encoding, protocol and 
transport independent (and portable), whereas JAX-RPC stubs are not defined in a 
25 standard and are closely tied (in this example) to the SOAP encoding. 

The infrastructure to support stub 110 operation is described below. The 
following subsections relate to the remote processing steps listed earlier. They show in 
detail how stub operations are supported by the PEPt architecture. 

30 

In the remainder of this disclosure, input and output streams are referred to as 
input and output objects to emphasize the fact that they do not need to be streams (e.g., 
they may contain graphs). Instead, they may be a source and sink of data. Their 
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implementation is not specified. 

Get a connection to the service 

In the above example, when a client invokes an operation of a remote service 210, 
5 it is calling a method on a stub 110. The steps taken on the client side when a stub 
method is invoked are described above. The stub 110 interacts with the PEPt architecture 
to service the request. The first step taken may be to obtain a connection to the remote 
service 210 in order to transport request and replies. 

10 To obtain a connectionrin one-embodiment it may be necessary to determine the 

type of connection and have a factory for the chosen type. To accomplish this, the client 
side of the PEPt transport block may have two main interfaces: Contactlnfo 132 and 
Connection 130. Contactlnfo 132 is an abstract representation of remote references and a 
factory for Connections 130. Connection 130 is the interface used to transport requests 

15 and replies. 

The protocol block interacts with Contactlnfo 132 to determine information such 
as location, transport, protocols, encodings, transaction, security, and to create a specific 
type of connection 130. The protocol block 104 A interacts with the Connection 130 by 
20 sending and getting raw bits transported by the connection 130. In one embodiment, 
Connection 130 and Contactlnfo 132, along with the Acceptor 134 discussed below, may 
be a form of the Acceptor-Connector design pattern. 

In some embodiments, since a connection 130 may come in many forms (e.g. 

25 shared memory, Solaris Doors, a TCP/IP connection, ATM, etc), other blocks in the 
system may not know the specific type of transport being used. In particular, the 
presentation block 100A may not know anything about the type of connection 130. In 
one embodiment, the type of the connection (transport), the encoding and the protocol 
may be able to change dynamically between invocations with no changes necessary at the 

30 presentation block 100A. For example, it may be useful to use SOAP/HTTP when an 
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RPC needs to traverse the Internet, but, within an enterprise, using an encoding, protocol 
and transport that utilizes the internal reliable LAN may be more appropriate. 

In one embodiment, to obtain a connection 130, the protocol block 104 A may 
5 interact with Contactlnfo 132 (this protocol block interaction is discussed later). For 
CORBA, this may mean examining an IOR (HOP Object Reference) that may contain a 
TCP/IP host/port pair. Since the CORBA HOP protocol allows request/reply 
multiplexing on single connection, an existing connection 130 may be used or a new 
connection 130 created if one is not found. 

10 

The point at which a connection 130 is obtained is dependent on the features 
supported by a specific type of RPC. In RMI-HOP, connections 130 are obtained before 
marshaling because of GIOP (General InterOrb Protocol) fragmentation and Portable 
Interceptors. If a GIOP implementation supports fragmentation, and if a Portable 
15 Interceptor adds service contexts to the GIOP header which overflow the internal buffer 
containing the encoded header, then one or more fragments may be sent. A connection 
130 is needed in order to send a fragment. Thus, the connection 130 is preferably 
obtained before marshaling. To accomplish this, a connection 130 is obtained during the 
call to _request in the RMI-HOP stub. 

20 

A different RPC system may obtain the connection 130 during the call to _invoke. 
This may necessitate buffer copying from buffers holding the arguments into the 
connection's output stream which may be avoided if the connection 130 is obtained before 
marshaling. 

25 

In JAX-RPC, the connection 130 may be obtained during the call to _send. 
However, to support HTTP persistent connections, DIME (Direct Internet Message 
Encapsulation) chunking, etc., it may be necessary to obtain a connection 130 earlier in 
the stub 110 code. 

30 
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A PEPt implementation of RMI-HOP .request or JAX-RPC _send may interact 
with Contactlnfo 132 to determine and create the appropriate Connection 130. In RMI- 
HOP, Contactlnfo 132 may abstract an IOR. The IOR may contain multiple profiles or 
tagged components which may specify different ways to connect to the service. In JAX- 
5 RPC, Contactlnfo 132 may abstract a reference such as http://.... In this case, an HTTP 
(i.e., TCP/IP) transport connection is to be used. 

PEPt may use the Contactlnfo 132 and Connection 130 interfaces of the transport 
block 106 A to enable alternate transports. Contactlnfo 132 may also serve as a factory to 
10 enable alternate encodings and~ protocols. Thus, Contactlnfo 132 may be the primary 
client-side pluggability point in the PEPt architecture. 

An exemplary method for writing and reading data on the obtained connection to 
the remote service 210 is discussed next. 

15 

Get an output object for the connection. 

The purpose of a transport block 106 A Connection 130 is to carry requests and 
responses between peers. The actual forming and processing of those requests/responses 
may take place in other PEPt blocks. To form the request, the procedure arguments are 
20 encoded. A way to convert from the presentation block 100 A representation of 
arguments to the RPC representation (encoding) of those arguments is provided. In PEPt, 
Output object and Input object are encoding block interfaces that contain and hide the 
encoding from other blocks. How they are obtained and used is discussed next. 

25 Once a transport connection 130 is obtained, it may be necessary to obtain an 

output object to be used for marshaling data. In one embodiment, the connection 130 
may be asked for an output object, but that may limit the output object to one type of 
protocol association and it may limit the connection 130 to one encoding/protocol 
combination. In another embodiment, since the remote reference (which is represented in 

30 PEPt by Contactlnfo 132) may include the necessary information on what encodings and 
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protocols may be used, it may serve as a factory for the output object. 

An output object may serve several functions. An output object's interface may 
define the presentation block 100A data types that may be written to the output object. Its 
5 implementation may define the encoding of those types. An output object's 
implementation may also define a private contract between the output object and the 
connection 130 on how that encoding is stored before being sent (e.g., as an array of 
. bytes). 

10 The output object is obtained at the following points in the example stubs: [CS1] 

- RMI-IIOP: _request - JAX-RPC: getRequest. Once the output object is obtained, 
presentation block 100A data may be marshaled into it, which is discussed next. 

Marshal the arguments into the output object. 
15 At this level, marshaling may be straightforward. The presentation block 100A 

stub 110 gives presentation block data types to the encoding block 102A output object to 
encode and temporarily store in internal storage: [CS2] RMI-IIOP: write_value - JAX- 
RPC: setlnputString, etc. 

20 In RMI-IIOP, marshaling may be complicated since it may need to support 

chunking, fragmentation, indirections, etc. Likewise, JAX-RPC marshaling may become 
involved in order to support MIME (Multipurpose Internet Mail Extensions) attachments. 
For example, to support a feature such as GIOP fragmentation, PEPt may allow encoding 
block output objects to make private contracts with the protocol block 104A and with the 

25 transport block 106 A Connection 130. These contracts may enable encoded buffers in 
the output object to be sent on the Connection 130 before the presentation block 100A is 
done marshaling. 

Marshaling complete, send the arguments to the service 
30 After the stub 110 has finished marshaling arguments, the stub 110 signals the 



Atty. Dkt. No.: 5681 -6430 1/P9233 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 



PEPt architecture that request argument marshaling is complete: [CS3] RMI-IIOP: 
_invoke - JAX-RPC: _send. 

At this point, the encoded arguments (or the last fragment of encoded arguments) 
5 may be sent over the transport 106 A. Before the encoded data is actually sent by the 
PEPt RPC infrastructure, the encoded data may be framed by protocol information. In 
one embodiment, protocol framing may be handled by the protocol block 104A Request 
dispatcher 120AA interface. In one embodiment, Request dispatcher 120AA may be 
responsible for managing necessary headers (and trailers if present), and for giving the 
10 output object's internal encoded data buffers to transport 106 A to be sent on the wire. - 

In one embodiment, since Contactlnfo 132 abstracts the 
encoding/protocol/transport combinations available for a specific service, Contactlnfo 
132 may serve as a factory for protocol block 104A objects (e.g. Request dispatcher 

15 120AA and Protocol Handler 122), as well as for transport block 106A and encoding 
block 102A objects. Since the protocol block 104A coordinates interactions between the 
other blocks, an interface is responsible for initially interacting with Contactlnfo 132 in 
order to choose and create a Request dispatcher 120 A A. In one embodiment, PEPt 
handles this by associating a generic Request dispatcher 120AA with the stub 110. The 

20 generic Request Dispatcher's function is to interact with Contactlnfo 132 to choose and 
create a specific Request dispatcher 120AA. Then, the specific Request dispatcher 
120AA takes over. The specific Request dispatcher 120 A A then interacts with 
Contactlnfo 132 to create the Connection 130 and Output Object. 

25 In one embodiment, the choosing and creation of Request dispatcher 120AA, 

Connection 130, and Output Object may occur when the stub 110 obtains an output 
object for marshaling. This is typically the case, since protocol information may need to 
be marshaled into the output object's internal encoded data storage even before beginning 
argument marshaling. There are two primary examples of the need to create the three 

30 block objects at this time. First, to use one continuous buffer (rather than separate buffers 
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for headers, data, and trailers and the use of scatter/gather 10), the Request dispatcher 
120AA may need to write headers into the Output Object before it is returned to the stub 
110 for marshaling. The Output Object needs to agree with the Connection 130 on the 
form of the internal buffer used between them. Second, as mentioned above, in RMI- 
5 HOP there is a possibility of having interceptors insert service contexts into headers that 
may cause an overflow of the buffer when using GIOP fragmentation. In this case, the 
Request dispatcher 120AA may need to create a fragment message and give it to the 
Connection 130 for sending even before marshaling begins. 

10 The discussion above describes how and when the main interfaces of- the four 

blocks are created, and how they are coordinated by the Request dispatcher 120AA 
protocol block 104A interface to marshal and send a request. How the reply is received 
and processed is examined below. 

15 Wait for a response. 

After the request is sent, the client side waits for a response from the server. The 
operation of waiting for a response may be dependent on the protocol being used. For 
example, when using HTTP, waiting for a response may involve blocking on a read of the 
connection on which the request was sent. In RMI-HOP, which allows message 

20 multiplexing on a single connection, it may be necessary to demultiplex incoming replies. 
Therefore, PEPt gives the Request dispatcher 120 A A control over how to wait for a reply. 

An HTTP Request dispatcher 120 A A may simply block on a read of the 
connection 130. In RMI-IIOP, since different reply messages (and possibly error and 

25 close connection messages) can arrive at any time, the RMI-HOP Request dispatcher 
120AA may interact with a Contactlnfo 132 factory to create an appropriate protocol 
block 104A Protocol Handler object 122. The Protocol Handler 122 listens on the 
connection 130 for incoming messages (note, issues such as scalability using a "selector" 
for listening, or "non-listening" transports like Solaris doors are not discussed here). The 

30 RMI-HOP Request dispatcher 120AA may put itself to sleep waiting for the Protocol 
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Handler 122 to signal that a matching reply has arrived. 

Note that the Request dispatcher 120 A A and the Protocol Handler 122 taken 
together may be viewed as a form of subcontract. 

Get an input object for the connection. 

When a reply arrives on the connection 130, an input object may be obtained for 
the connection 130 so that headers and the remote procedure's result may be read. The 
example stubs obtain an input object at the following points: [CS4] RMI-HOP: Jnvoke - 
JAX-RPC: getResponse: The following describes an example ot what the .. PEPt 
architecture does at these points to provide an input object to the stub 1 10. 

When a reply arrives at the connection 130, the connection 130 provides the raw 
bits of the reply to the Protocol Handler 122. The Protocol Handler 122 examines the 
15 raw bits to determine the protocol in use (if the connection 130 is supporting multiple 
profiles). The Protocol Handler 122 then asks Contactlnfo 132 to create an appropriate 
Input Object. In one embodiment, a protocol may use the presentation block 100A data 
types to read and write headers and trailers. 

20 In the RMI-HOP case, after the Input Object has been created, the Protocol 

Handler 122 may read from it to determine the GIOP version, whether this is the first, 
continuing or last fragment of a reply or a complete (non-fragmented) reply, and to obtain 
the request ID. When the reply is non-fragmented or the first fragment of a reply, the 
Protocol Handler 122 may use the request ID to find the matching request. The Protocol 

25 Handler 122 then gives the Input Object to the waiting Request dispatcher 120AA and 
signals the Request dispatcher 120 A A to wake up to handle the reply. When the reply is 
a continuing or last fragment, the Protocol Handler 122 may use the request ID to find an 
existing Input Object (created upon receiving the first fragment). The Protocol Handler 
122 then gives the existing Input Object the raw bits of the reply. This forms a 

30 producer/consumer relationship between the Protocol Handler 122 and an existing Input 



5 



10 
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Object. 



Once the reply has been matched with a request, the Request dispatcher 120AA 
may return the input object to the stub 110. The input object may be positioned to start 
5 reading the marshaled reply (the Protocol Handler/Request Dispatcher having already 
read the header information). As noted above, if fragmentation is in effect, there may be 
a private contract between the Connection 130, the Protocol Handler 122 and the Input 
Object such that, as more fragments arrive for a particular reply, those fragments can be 
passed to the internal buffers of the input object. The input object then serves the role of 
10 a shared buffer between the stub- 110 (consuming the input object) and the 
Connection/Protocol handler (filling the input object). 

Unmarshal the result of a remote invocation and cleanup . 

The protocol block 104A Request dispatcher 120A returns control and an 
15 encoding block Input Object to the stub 110 when a reply has been received. The stub 
110 uses the Input Object to unmarshal the type-specific reply: [CS5] RMI-HOP: 
read_value, read_string - JAX-RPC: getValue, etc., which is then returned in the form of 
a normal return value [CS6] or exception [CS7]. The Input Object acts as a bridge 
between the encoding block 102A and the presentation block 100A. 

20 

Before returning control to user code, the stub 110 signals the RPC infrastructure 
that it may clean up any resources used for this invocation. In RMI-HOP, this is seen in 
the call to [CS8] _releaseReply. Example resources are fragment maps which map 
request IDs to input objects, the input/output objects used in the request, etc. The 
25 example JAX-RPC stub does not have an explicit "cleanup" call. 

The above description of a client remote invocation from the vantage point of 
exemplary RMI-HOP and JAX-RPC stubs illustrates how the PEPt architectural blocks 
(presentation 100A, encoding 102A, protocol 104A and transport 106A) may support 
30 RPC on the client side. Specific PEPt interfaces have been described which represent or 
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bridge each block. The server side of a remote invocation is described next. 



Server-Side Lifecvcle 

The following describes, according to one embodiment, how the PEPt architecture 
5 supports receiving a request on the server side, routing that request to an appropriate Tie 
and servant, and sending the servant's results back to the client. The PEPt blocks will be 
involved in roughly reverse order compared to the client side, as illustrated in Figure 3. 
Since many of the interactions are similar to the client side, this server side discussion is a 
bit terser, and some of the detail shown for the client side is not shown. 

10 

The following description of the server-side lifecycle of a client-server RPC 
system describes means for receiving encoded and protocol framed incoming messages 
over the interconnect, means for determining the intent of the encoded and protocol 
framed incoming messages, means for decoding representations of data types from the 
15 incoming messages, and means for providing the data types from the incoming messages 
to a program. 

On the server side, the programmer's view of a remote call is similar to a local 
call. If the code that implements the service is referred to as a "servant", then the servant 
20 code may include, but is not limited to: using the method arguments in the body of the 
, servant method to form a result; if there are no problems, return the result; if there are 
problems, throw an exception. 

Expanding these to include infrastructure steps (to be discussed in detail below) 
25 the server-side steps of servicing a request may include, but are not limited to: 

• Accept a connection from the client 200A. 

• Receive a request on the connection. 

• Get an input stream for the connection. 

• Find a Tie and servant. 

30 • Use input stream [SSI] to unmarshal arguments. [SS2] 
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Call the servant with the unmarshaled arguments. [SS3] 

- Use the method arguments in the body of the servant method to form a 
result. 

- If no problems, return the result. 

- If problems, throw an exception. 
Get an output stream for the connection. [SS4] 
Marshal the result or exception. [SS5] 
Marshaling reply completed. [SS6] 
Send the reply. 

Release any resources used in the remote call . 

The following description shows how PEPt supports these steps. The labeled 
steps - e.g., [SSI] - relate the steps to code in example Ties and the following discussion 
of how that code connects to the PEPt architecture in the server side lifecycle. These 
15 steps are described below in more detail and related to concrete RMI-HOP and JAX-RPC 
examples. 

Accept a Connection 

As seen above, the client communicates with a server via a Connection. The 
20 server accepts the client's connection request and creates a PEPt transport Connection 
object 130B on which to receive requests and send replies to the client. Accepting 
connections is a transport block 106B operation handled by an Acceptor 134 interface on 
the server side. 

25 Receive a Request 

Once the connection has been accepted, the server will then monitor the 
connection for incoming requests. Receiving the raw bits of a request is a transport block 
106B operation. When a request arrives, the connection 130B gives the raw bits of the 
request to its associated Acceptor 134, which acts as a factory for a Protocol Handler 

30 122B. This gives connections 130 the ability to handle multiple protocols by delegating 



5 
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the creation of the Protocol handler 122B to the Acceptor 134, which may decode some 
portion of the initial raw bits to determine the protocol in use and create the appropriate 
protocol handler 122B. Determining the protocol in use is a protocol block 104B 
operation. 

5 

Get a Request Input object and Unmarshal Header 

Once the Protocol handler 122B has determined the protocol in use, the Protocol 
handler 122B asks the Acceptor 134 to act as a factory for an Input object for the 
connection. In many cases, there may be nothing to discriminate when only one protocol 

10 is in use, except to ensure that the bits are indeed a protocol message - typically via.some 

bits at the start of the message. 

The Protocol handler 122B reads message headers from the Input object to 
determine the intent (e.g., type) of the message. Message discrimination is a protocol 

15 block 104B operation. The Protocol handler 122B may use header information to 
determine which Request Dispatcher 120B to use to handle the request or it may delegate 
this determination to the Acceptor 134. The Protocol handler 122B is logically separate 
from the Request Dispatcher 120B so that if any errors occur during header processing 
(e.g., header unmarshaling errors), Protocol handler 122B may form a reply appropriate 

20 for the protocol to send to the client. 

Note that the Acceptor 134 is the server side factory for Connections 130, 
Protocol handlers 122B, Request Dispatchers 120B, Input objects and Output objects. 
Thus, Acceptor 134 is the primary server-side pluggability point in the PEPt architecture 
25 (similar to Contactlnfo 132 on the client-side). 

Find a Tie 

If no header processing errors occur, the Protocol handler 122B gives control of 
further processing to the Request dispatcher 120B that finds the appropriate type-specific 
30 Tie 112B and servant. Tie 112B is responsible for converting encoding block 
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representations of arguments to presentation block representations of arguments 
(unmarshaling), calling the actual servant procedure of remote service 210 which 
processes the arguments, then marshaling the results or exception of the servant 
procedure. In RMI-HOP, the Request dispatcher 120B may locate the Tie 112B/servant 
5 using the Portable Object Adapter. In JAX-RPC, finding a Tie/servant may involve 
deployment descriptors that map URLs to Ties and servant procedures. 

Unmarshal Request Arguments and Call Servant 

To make the discussion concrete, the following examples illustrate RMI-HOP and 
10 JAX-RPC Ties. Portions of the Tie code are referred to below in the discussion olserver- 
side request processing. The following is an example of an RMI-HOP Tie and is not 
intended to be limiting: 



public OutputStream _invoke( 
15 String method, InputStream _in, [SS1] ResponseHandler reply) 

throws System Exception 

{ 

try { 

if (method.equalsfechoString")) { 
20 String argO = (String) _in.read_value(String.class); [SS2] 

String result = target.echoString(argO); [SS3] 
OutputStream out = reply.createReply();[SS4] 
out.write_value(result, String.class); [SS5] 
return out; [SS6] 

25 } 

throw new BAD_OPERATION(); 
} catch (System Exception ex) { 

throw ex; 
} catch (Throwable ex) { 
30 throw new UnknownException(ex); 

} 

} 

The following is an example of a JAX-RPC Tie and is not intended to be limiting: 
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private void invoke_echoString(StreamingHandlerState state [SS1] ) 
throws Exception 

{ 

RIBaselF_echoString_RequestStruct xx = null; 

Object xxObj = state.getRequest().getBody().getValue();[SS2] 

if (xxObj instanceof SOAPDeserializationState) { 

xx =(RIBaselF_echoString_RequestStruct) 

((SOAPDeserializationState)xxObj).getlnstance(); 
} else { 

xx =(RIBaselF_echoString_RequestStruct)xxObj; 

} - ~"~ 

java.lang. String ^return = 

((RIBaselF) getTarget()).echoString(xx.getlnputString());[SS3] 
RIBaselF_echoString_ResponseStruct yy = 

new RIBaselF_echoString_ResponseStruct(); 
SOAPHeaderBlocklnfo headerlnfo; 
yy.set_return(_return); 
SOAPBIocklnfo bodyBlock = 

new SOAPBIocklnfo(nSS1_echoString_echoStringResponse_QNAME); [SS4] 
bodyBlock.setValue(yy); [SS5] 
bodyBlock.setSerializer(yy_SOAPSerializer); 
state.getResponse().setBody(bodyBlock); 
[SS6] 

} 

Like stubs, both Tie classes have similar structure and similar differences (e.g., 
RMI-IIOP Ties are encoding, protocol and transport independent and portable, JAX-RPC 
Ties are closely coupled, in this example, to SOAP). 

The steps the Ties take to unmarshal arguments and call a servant procedure may 
include one or more of, but are not limited to: 

• get an input object: [SSI] RMI-IIOP: _in - JAX-RPC: state. getRequest 

• unmarshal encoded arguments: [SS2] RMI-IIOP: read_value - JAX-RPC: 
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getValue, etc. 

call the servant procedure with presentation block data types: [SS3] RMI-EOP: 
targetechoStringO..) - JAX-RPC: getTarget().echoString(...) 



5 Get a Reply Output Object 

Once the servant procedure has returned a result or thrown an exception, the Tie 
112B is responsible for getting an output object in which to marshal the result: [SS4] 
RMI-IIOP: createReply - JAX-RPC: SOAPBlocklnfo. 

10 The presentation block 100B Tie 112B gets an output object by interacting with 

the protocol block 104B Request dispatcher 120B (which in turn will interact with the 
transport block 106B Acceptor 134 and Connection 130B to obtain the correct type of 
output object. The protocol block 104B may write reply headers into the output object 
(which may result in fragments of the reply being- sent on the Connection 130B). Note 

15 that, in one embodiment, RMI-HOP's ResponseHandler may be viewed as a standard 
interface to Request dispatcher 120B. 

Marshal Reply 

Marshaling a server-side reply is similar to marshaling client-side arguments: 
20 [SS5] RMI-HOP: write_value - JAX-RPC: set_return, set_value, etc. The Tie 130B 
marshals presentation block 100B result types to encoding block 102B representations. 
The Output object bridges between the presentation block 100B and the encoding block 
102B. Note that, as on the client-side, the protocol 104B and transport 106B blocks may 
be involved if fragmentation occurs. 

25 

Marshal Complete and Cleanup 

When marshaling is complete, the presentation block 100B Tie 112B signals the 
protocol block 104B's Request dispatcher 120B and Protocol handler 122B to resume 
control: [SS6] RMI-HOP: return out - JAX-RPC: returning after 
30 state.getResponseQ.setBody(bodyBlock)). The protocol block 104B takes the encoded 
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framed data and sends it to the client on the transport block 106B Connection 130B. 



Any resources used while processing the request may then be cleaned up under 
control of the Request dispatcher 120B and/or Protocol handler 122B. On the client side, 
5 cleanup occurs in the stub 110A, since it is the last point of control that knows that an 

r .... 

invocation is complete. On the server side, the cleanup occurs in the protocol block 104B 
rather than the Tie 112B, since the protocol block 104B has control after the Tie 112B 
completes. 

10 The above examples illustrate how the-PEPt architecture- may service a remote 

invocation, according to some embodiments. The transport block 106B accepts a 
connection and receives a request. The transport block 106B acts as a factory for other 
block objects. The protocol block 104B determines the request type and finds a Tie 112B 
and servant procedure of the remote service to handle the procedure call. The 

15 presentation block 100B unmarshals the arguments from the encoding block 102B and 
calls the servant of the actual procedure. The presentation block 100B marshals the 
servant procedure's result to the encoding block 102B. The protocol block 104B frames 
the result and gives the framed encoded data to the transport block 106B to send to the 
requester. The protocol block 104B then cleans up. 

20 

The above examples illustrate that the steps taken to invoke and service a remote 
procedure may be essentially the same regardless of the specific presentation block types 
and APIs, encodings, protocols and transports used. Figures 4 and 5 are tables that 
summarize the blocks and interfaces used at each step according to one embodiment. The 

25 table illustrated in Figure 4 summarizes the blocks and interfaces used at steps for the 
client side according to one embodiment. The table illustrated in Figure 5 summarizes 
the blocks and interfaces used for the server side according to one embodiment. Note that 
fragmentation may happen any time an output or input object is written or read. Which 
blocks are involved in fragmentation are indicated in rows labeled "(fragmentation)" in 

30 the tables of Figures 4 and 5. 
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Figures 6 and 7 is a flowchart illustrating a method of implementing a remcrte 
procedure call system using the PEPt architecture according to one embodiment. Figure 6 
is a flowchart illustrating a method of sending outgoing messages on a remote procedure 
5 call system using the PEPt architecture according to one embodiment. As indicated at 
200, a presentation block on a system may present data types and Application 
Programming Interfaces (APIs) available to a program on the system. The APIs may be 
configured to provide an interface to the remote procedure call system to the program on 
the system. As indicated at 202, an encoding block may encode representations of those 

. 10 data types-(for-data received from the_program) as- outgoing messages-on.aninterconnect. 

In one embodiment, to encode representations of those data types as outgoing messages, 
the encoding block may convert representations of data provided by the program to 
representations of data for use by the remote procedure call system. In one embodiment, 
the encoding block may generate a text encoding of the data types. In one embodiment, 

15 the encoding block may generate a binary encoding of the data types. As indicated at 
204, a protocol block may frame the encodings to denote the intent of the outgoing 
messages. In one embodiment, the protocol block may denote if the outgoing messages 
are request messages or response messages to request messages received by the program. 
In one embodiment, if the messages are response messages, the protocol block may 

20 determine if the response message is an error message and, if so, denote in the outgoing 
message that the message is an error message. As indicated at 206, a transport block may 
move the encoded and protocol framed outgoing messages from the system to a remote 
system over the interconnect. In one embodiment, the transport block may move the 
encoded and protocol framed outgoing messages from the system to the remote system 

25 over the interconnect using TCP/IP. In other embodiments, other transports may be used 
to move the outgoing messages over the interconnect. 

Figure 7 is a flowchart illustrating a method of receiving incoming messages on a 
remote procedure call system using the PEPt architecture according to one embodiment. 
30 As indicated at 210, the transport block may receive encoded and protocol framed 
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incoming messages from the remote system over the interconnect. As indicated at, 2 12, 
the protocol block may determine the intent of the encoded and protocol framed incoming 
messages. In one embodiment, the protocol block may determine if the incoming 
messages are reqeuest messages or response messages. In one embodiment, the protocol 
5 block may determine if the incoming messages are error messages and, if so, either 
handle the error message itself or alternatively pass the error message on to the encoding 
block to be handled elsewhere. As indicated at 212, the encoding block may decode 
representations of data types from the incoming messages and pass the decoded data on to 
the presentation block. As indicated at 214, the presentation block may then provide the 
10 decoded data types from the incoming messages to the program on the system. 

Conclusion 

Various embodiments may further include receiving, sending or storing 
instructions and/or data implemented in accordance with the foregoing description upon a 

15 carrier medium. Generally speaking, a carrier medium may include storage media or 
memory media such as magnetic or optical media, e.g., disk or CD-ROM, volatile or non- 
volatile media such as RAM (e.g. SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), 
ROM, etc. As well as transmission media or signals such as electrical, electromagnetic, 
or digital signals, conveyed via a communication medium such as network and/or a 

20 wireless link. 

The various methods as illustrated in the Figures and described herein represent 
exemplary embodiments of methods. The methods may be implemented in software, 
hardware, or a combination thereof. The order of method may be changed, and various 
25 elements may be added, reordered, combined, omitted, modified, etc. 

Various modifications and changes may be made as would be obvious to a person 
skilled in the art having the benefit of this disclosure. It is intended that the invention 
embrace all such modifications and changes and, accordingly, the above description to be 
30 regarded in an illustrative rather than a restrictive sense. 
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